The invention relates to defining a context identifier when compressing header fields of data packets.
The rapid progress in IP (Internet Protocol) technology during the last few years has also expanded the potential of using different IP-based applications outside the conventional Internet data transfer. IP-based telephony applications in particular have developed at a fast pace, as a result of which an ever expanding part of the call transmission path even in conventional telephone networks (PSTN/ISDN, Public Switched Telephone Network/Integrated Services Digital Network) and mobile networks (PLMN, Public Land Mobile Network) can, in principle, be implemented by utilising IP technology.
Especially in mobile networks, IP technology offers many advantages, since in addition to the conventional voice services of mobile networks, which could be provided by means of various IP voice applications, mobile networks will provide more and more different data services, such as Internet browsing, e-mail services, games, etc., which are typically most preferably implemented as packet-switched IP-based services. This way, IP layers arranged in mobile system protocols could serve both audio/video services and various data services.
In mobile networks, it is especially important to utilise the limited radio resources as efficiently as possible. This, for its part, complicates the utilisation of the IP protocols in the radio interface, because in IP-based protocols, the proportion of various header fields of the transferred data is very large, and correspondingly, the proportion of payload is small. In addition, the bit error rate (BER) of the radio interface and the combined round-trip time (RTT) of the uplink and downlink directions may in bad conditions increase a great deal, which causes problems in most known header field compression methods. This has created a need to develop a header field compression method suitable for different IP protocols, which would be especially suited for data transfer over the radio interface: efficient header field compression which can, however, be used in conditions in which bit error rates and round-trip times increase a great deal.
For this purpose, IETF (Internet Engineering Task Force) has lately been working on the standardisation of a header field compression method known as ROHC (Robust Header Compression). One idea behind the development of ROHC is that there is a great deal of redundance between the several IP header fields used in data packet transfer, not only inside the data packet, but also between them. In other words, a large amount of the information in the header fields does not change at all during the transfer of the data packets and is thus easy to reconstruct even though it is not transmitted. Only a small part of the header fields are such that the information they comprise requires attention during compression. Further, ROHC comprises several compression levels, whereby the efficiency of the compression increases when moving on a higher level. ROHC always tries to use the most efficient compression possible, in such a manner, however, that before moving on to the next level, a sufficient reliability of operation of the level is always ensured. ROHC also has the typical characteristic that it leaves several matters essential for the use of a compression method to be handled by the lower link layer.
One such matter to be negotiated through the lower link layer between a sender and a receiver, i.e. compressor and decompressor, is the definition of the length of a context identifier (CID) used on a certain radio link. The context identifier CID is used to distinguish from each other several packet data flows transmitted on the same radio link. The length of the context identifier CID can be 0, 1 or 2 bytes (0, 8 or 16 bits), and the value zero is used when the link only has one data flow. The length of CID is thus negotiated before the compression of the data to be transmitted is started, and the negotiated length of the context identifier CID is used thereafter in both the uplink and downlink direction.
One problem in the arrangement described above is the inflexibility of the length of the context identifier CID. Since the length of CID has been negotiated before starting compression, its value can only be changed by re-negotiating it between the compressor and decompressor, in which case the compression must be stopped. Another problem is that when using one radio bearer, the same CID length must be used both in the uplink and downlink direction. However, in mobile systems, for instance, a preferable CID length in the uplink direction is typically considerably shorter than in the downlink direction. If in a prior art solution, the CID length is defined for a radio bearer on the basis of the downlink direction requirement, the uplink direction radio resources are then not used optimally. If the CID length is defined taking into consideration the uplink direction only, problems will arise in the downlink direction decompression, because the required CID length is longer than the negotiated CID length.